[00:00.000 --> 00:02.140]  Thank you everyone for tuning in.
[00:02.140 --> 00:05.240]  I'm super honored to be speaking here today at DEF CON.
[00:05.240 --> 00:07.520]  This is my first DEF CON talk.
[00:07.520 --> 00:10.420]  I'm super honored to be here today.
[00:10.980 --> 00:14.940]  And I wish that we can all have a normal DEF CON
[00:15.760 --> 00:18.440]  and we'd be able to meet everyone in person,
[00:18.440 --> 00:22.240]  but hopefully next year when life gets back to normal.
[00:23.040 --> 00:25.180]  Yeah, let's start.
[00:25.320 --> 00:26.980]  So who am I?
[00:27.000 --> 00:28.340]  I'm Mazen Ahmed.
[00:28.340 --> 00:29.780]  I'm a cyber security engineer
[00:30.430 --> 00:33.860]  and I specialize in offensive security and APSEC.
[00:34.180 --> 00:36.500]  I also founded Fullhunt.
[00:36.500 --> 00:37.940]  If you haven't heard about Fullhunt,
[00:37.940 --> 00:40.920]  it's the next generation assets discovery
[00:40.920 --> 00:43.900]  slash monitoring, slash scanning,
[00:43.900 --> 00:45.280]  slash a lot of cool things
[00:45.280 --> 00:47.160]  that are happening in the background.
[00:47.980 --> 00:50.160]  If you haven't tried it or checked it out,
[00:50.160 --> 00:51.280]  you should definitely do.
[00:51.280 --> 00:53.080]  It will be one of the coolest things
[00:53.080 --> 00:55.840]  in security one day soon.
[00:57.160 --> 01:00.000]  Before that, I worked in the security engineering
[01:00.000 --> 01:02.700]  of ProtonMail.
[01:02.820 --> 01:06.740]  I was also, I'm also a bounty participant
[01:07.320 --> 01:11.760]  where I reported security vulnerabilities to Facebook,
[01:11.760 --> 01:17.540]  to the Department of Defense, to Twitter, and many others.
[01:18.080 --> 01:22.740]  I'm interested in web, infra, mobile,
[01:22.740 --> 01:27.520]  and cloud security, life evasions, security automation,
[01:27.520 --> 01:32.200]  and DevSecOps, and many other cool things in security.
[01:33.040 --> 01:36.460]  And you can read more at mazenahmed.net
[01:36.460 --> 01:40.000]  and you can find my contact details there.
[01:41.520 --> 01:43.260]  And yeah, let's start.
[01:43.260 --> 01:44.660]  So the agenda for today,
[01:44.660 --> 01:46.920]  of course, we're talking about hacking Zoom.
[01:47.000 --> 01:50.500]  Before that, we need to have a quick intro about Zoom,
[01:50.500 --> 01:51.500]  just in case.
[01:52.740 --> 01:56.880]  And then we're gonna have a background, findings,
[01:56.960 --> 02:01.840]  a retrospective on the Zoom's last minute VDP,
[02:01.840 --> 02:04.560]  recommendations, final thoughts,
[02:05.040 --> 02:08.880]  and then we would have a room for Q&A.
[02:10.300 --> 02:12.860]  Zoom, everyone knows it today.
[02:12.860 --> 02:14.380]  Everyone is using it.
[02:14.380 --> 02:16.980]  It's literally in everywhere in the world.
[02:16.980 --> 02:20.680]  Every company, almost every company is using it.
[02:20.680 --> 02:24.040]  Governments use it too.
[02:24.340 --> 02:27.520]  We saw last week the hearing of the Twitter hack
[02:27.520 --> 02:31.380]  where the hearing was done via Zoom
[02:31.380 --> 02:36.900]  and that hack happened at the hearing live.
[02:36.900 --> 02:39.180]  It was quite bad, but yeah.
[02:39.180 --> 02:42.420]  So this proves that everyone is using it.
[02:44.070 --> 02:47.540]  In May, 2020, the market valuation for Zoom
[02:47.540 --> 02:51.620]  is 50 billion USD.
[02:53.520 --> 02:56.720]  I'd like to bring this chart here.
[02:56.720 --> 03:00.880]  This is a comparison between the market capital of Zoom
[03:00.880 --> 03:05.380]  against the top seven airlines in the world,
[03:05.380 --> 03:08.040]  including United and Delta.
[03:09.740 --> 03:16.800]  So combining the top seven airlines' market capital,
[03:16.800 --> 03:22.380]  they are either equal or have a higher market capital.
[03:22.380 --> 03:25.300]  This is crazy just to think about it,
[03:25.300 --> 03:27.140]  how Zoom became today.
[03:29.600 --> 03:33.600]  And the rise of Zoom started with the global pandemic.
[03:33.600 --> 03:35.180]  Everyone knows about that.
[03:38.200 --> 03:41.620]  So from a stock performance,
[03:41.620 --> 03:44.300]  almost all of the companies were in the same range
[03:44.300 --> 03:45.880]  as we can see here.
[03:45.880 --> 03:52.360]  And then it jumped, it actually skyrocketed by May
[03:52.360 --> 03:54.740]  with all what was happening.
[03:54.740 --> 03:58.460]  And meanwhile, all of these top airlines
[03:58.460 --> 04:03.120]  were quickly falling down, as we can see.
[04:04.360 --> 04:06.300]  For me, I just find this really interesting
[04:06.300 --> 04:08.820]  to imagine how Zoom became today.
[04:10.900 --> 04:14.820]  Yeah, and because how important is Zoom?
[04:14.820 --> 04:17.120]  This is where my research started.
[04:19.000 --> 04:23.620]  So in March, March 2020,
[04:23.620 --> 04:26.580]  Patrick Walder gave a talk at Opcode
[04:26.580 --> 04:32.440]  about the Zoom security and the state of security at Zoom.
[04:32.540 --> 04:35.760]  And he disclosed a number of security vulnerabilities
[04:35.760 --> 04:40.360]  in the Mac OS client of Zoom.
[04:40.880 --> 04:44.240]  And this brings a lot of attention
[04:44.240 --> 04:47.120]  to the media and to me personally.
[04:47.860 --> 04:49.960]  And from that, I got more interested
[04:49.960 --> 04:53.540]  and started my research from there.
[04:54.360 --> 04:57.180]  So what was tested before?
[04:58.680 --> 05:02.720]  The Zoom Mac OS app, it was tested.
[05:02.720 --> 05:05.140]  We can read about it in the media
[05:05.140 --> 05:08.320]  and we can read about it in researches
[05:08.320 --> 05:12.080]  done by Patrick Walder and many others.
[05:12.080 --> 05:14.660]  It was hacked, it was really bad,
[05:14.660 --> 05:17.040]  it was reusing really bad practices.
[05:18.040 --> 05:20.940]  There was a lot of Zoom privacy concerns
[05:21.560 --> 05:26.640]  and the way that Zoom is sharing data to Facebook
[05:27.010 --> 05:29.720]  and a lot of things we can also see.
[05:30.660 --> 05:33.840]  But what was not tested before?
[05:33.840 --> 05:36.040]  Of course, many things.
[05:36.240 --> 05:39.540]  This is, I can just share two,
[05:39.540 --> 05:42.420]  but many things has not been tested before.
[05:42.800 --> 05:47.280]  For me, I'm trying to take into a couple of things
[05:47.280 --> 05:49.500]  and that I will be showing now.
[05:50.040 --> 05:54.620]  One thing that was not tested was the Zoom Linux app.
[05:54.800 --> 05:59.080]  Nothing, I have tried to search about any research
[05:59.080 --> 06:03.400]  or disclosure for any vulnerability in the Zoom Linux client.
[06:03.400 --> 06:04.800]  I haven't seen anything.
[06:05.240 --> 06:07.560]  This is one thing that I wanted to see
[06:07.560 --> 06:09.980]  or to focus on.
[06:10.760 --> 06:14.620]  The Zoom external attack surface, Zoom became huge
[06:14.620 --> 06:18.420]  and there was no focus on the external attack surface
[06:18.420 --> 06:19.460]  of Zoom.
[06:20.680 --> 06:24.760]  The Zoom cloud infrastructure, how it's being set up
[06:24.760 --> 06:28.480]  and different things related to the infra.
[06:29.220 --> 06:31.680]  And of course, the Zoom's new end-to-end
[06:31.680 --> 06:34.200]  encryption implementation.
[06:34.200 --> 06:35.880]  We have seen it to the media.
[06:35.880 --> 06:37.760]  Did anyone test it?
[06:38.000 --> 06:41.000]  We can talk about that later.
[06:41.020 --> 06:42.280]  And of course, many.
[06:42.620 --> 06:45.440]  There are a lot of things, I only focused on these.
[06:45.440 --> 06:47.840]  Definitely, there is a lot of room for research
[06:47.840 --> 06:49.200]  in this area.
[06:51.560 --> 06:55.900]  So the findings agenda, I'm not gonna go
[06:55.900 --> 06:57.680]  to each one of them now.
[06:57.680 --> 06:59.580]  We will talk about them later.
[06:59.580 --> 07:02.040]  It's just here for people who are curious
[07:02.040 --> 07:04.780]  to see what we're gonna talk about.
[07:07.730 --> 07:12.690]  A quick disclaimer, the entire research is non-funded.
[07:12.690 --> 07:14.290]  This is a non-funded research.
[07:14.290 --> 07:17.270]  I have done everything here in my spare time,
[07:17.730 --> 07:21.790]  just to confirm that or state that.
[07:23.150 --> 07:25.990]  The research background, the first finding
[07:25.990 --> 07:28.890]  that I identified was in April, 2020.
[07:29.590 --> 07:33.810]  And my expectations did not match what I was seeing
[07:33.810 --> 07:35.150]  in the media.
[07:35.450 --> 07:38.310]  We will know how later.
[07:38.870 --> 07:41.930]  The first conclusive response for my finding
[07:41.930 --> 07:48.010]  that I reported in April, 2020, I got it in July.
[07:49.070 --> 07:54.990]  This wasn't a very pleasing experience.
[07:55.430 --> 07:59.530]  And this after a lot of follow-ups, of course, from my side.
[07:59.530 --> 08:02.130]  And after submitting the CFP to Defcon,
[08:02.130 --> 08:05.130]  the second round of research started.
[08:05.130 --> 08:08.550]  At that time, I identified additional
[08:08.550 --> 08:10.350]  six new different vulnerabilities
[08:11.070 --> 08:14.270]  and security-related issues.
[08:14.570 --> 08:18.410]  And of course, everything was reported to Zoom.
[08:19.630 --> 08:24.430]  And the reward was zero dollars.
[08:24.430 --> 08:27.510]  Yeah, I just want to say that.
[08:30.880 --> 08:34.720]  So the first step for doing any type
[08:34.720 --> 08:39.520]  of offensive research is the reconnaissance.
[08:40.140 --> 08:43.060]  Understanding the attack surface.
[08:43.060 --> 08:45.480]  And that's where I started with.
[08:47.460 --> 08:51.660]  I used full-hunt.io to get the Zoom details.
[08:52.220 --> 08:56.100]  API returned around 13 domains.
[08:56.100 --> 09:01.160]  And this is the list of domains that was discovered.
[09:02.160 --> 09:06.700]  I took a portion of them and analyzed them.
[09:06.740 --> 09:09.480]  The remaining are there.
[09:09.480 --> 09:14.520]  If anyone would like to have a test drive, feel free.
[09:16.360 --> 09:19.080]  And let's go to the findings.
[09:22.790 --> 09:26.670]  One thing that I noticed that there was two servers
[09:26.670 --> 09:31.490]  that are having a Kerberos service running.
[09:32.450 --> 09:33.990]  And when I saw that,
[09:33.990 --> 09:37.770]  I got interested to see what's happening there.
[09:37.970 --> 09:42.650]  Apparently, there was two exposed Kerberos servers
[09:42.650 --> 09:45.890]  that was exposed unintentionally to the internet
[09:46.330 --> 09:48.870]  and no one knew about them.
[09:50.310 --> 09:56.930]  So this one had also a web service running on port 80
[09:56.930 --> 09:59.170]  and it was FreeIPA.
[09:59.170 --> 10:01.190]  If you don't know what's FreeIPA,
[10:01.190 --> 10:03.370]  it's an identity management solution
[10:03.800 --> 10:06.070]  that was developed by Red Hat.
[10:07.230 --> 10:10.330]  It's open source, you can check it out.
[10:13.340 --> 10:17.700]  And I started by testing the web interface.
[10:17.880 --> 10:20.600]  As you can see, this screenshot,
[10:20.600 --> 10:24.420]  when you are providing an invalid username,
[10:24.420 --> 10:27.980]  you can see that there is a Kerberos error
[10:27.980 --> 10:29.800]  that is telling you that.
[10:29.800 --> 10:32.320]  And one thing that I did not mention here,
[10:32.320 --> 10:35.420]  that whenever you see a Kerberos server running,
[10:36.840 --> 10:39.780]  by itself, it's not huge,
[10:39.780 --> 10:41.560]  but once you compromise it
[10:41.560 --> 10:45.400]  or you have a single credential that is valid,
[10:46.820 --> 10:51.900]  then this would open a crazy large amount
[10:51.900 --> 10:55.100]  of attack surface for you to attack.
[10:55.160 --> 10:57.260]  And that's what I was doing.
[10:57.300 --> 10:59.460]  I want to get initial foothold there
[10:59.460 --> 11:02.540]  and then go from there.
[11:03.640 --> 11:06.980]  So I started doing user enumeration there.
[11:06.980 --> 11:09.980]  And you can see here,
[11:09.980 --> 11:13.260]  the previous one was showing that there was an error.
[11:13.260 --> 11:17.040]  This user is not found by the client.
[11:18.700 --> 11:21.520]  And here it's saying that the authentication failed
[11:21.520 --> 11:23.380]  or the pre-authentication failed,
[11:23.380 --> 11:29.440]  which means that we are able to identify
[11:29.970 --> 11:31.980]  valid usernames.
[11:33.240 --> 11:36.720]  And then I started building word list
[11:36.720 --> 11:40.460]  based on different things to identify more usernames
[11:40.750 --> 11:44.310]  so that I can brute force them.
[11:45.280 --> 11:51.680]  I compiled the word list from the pattern that I have seen.
[11:51.680 --> 11:56.500]  So the pattern that I have seen for the Zoom emails
[11:56.500 --> 12:01.740]  are firstname.lastname at zoom.us.
[12:01.760 --> 12:06.760]  Also the common usernames that I was able to find to get
[12:06.760 --> 12:08.900]  and employee names, of course.
[12:08.900 --> 12:14.580]  I compiled them all and I did that for user enumeration.
[12:14.580 --> 12:20.740]  The only users that I found was admin at idm.mezoom.us.
[12:21.450 --> 12:26.970]  I then ran a number of brute force sessions on them.
[12:27.560 --> 12:30.820]  Nothing interesting happened.
[12:31.100 --> 12:36.160]  Then I saw that I'm hitting a rabbit hole
[12:36.160 --> 12:38.460]  and it's a dead end.
[12:38.460 --> 12:42.060]  So I just moved to another more interesting thing
[12:42.060 --> 12:43.350]  that I can find.
[12:46.160 --> 12:50.060]  And yeah, it was a good choice.
[12:50.840 --> 12:53.020]  So the discovery of a memory leak
[12:53.020 --> 12:56.100]  on our Zoom production server.
[12:59.340 --> 13:03.920]  Zoom allows uploading profile pictures on accounts,
[13:03.920 --> 13:05.820]  which is the typical thing.
[13:06.720 --> 13:10.200]  The process for that is first,
[13:10.200 --> 13:12.660]  the user uploads a profile image.
[13:13.420 --> 13:20.140]  And the profile image is either JPEG, GIF, or PNG.
[13:20.840 --> 13:22.980]  And this is the tricky one.
[13:22.980 --> 13:28.660]  If the image is PNG or GIF, it's converted to JPEG.
[13:28.660 --> 13:32.180]  And if the image is JPEG,
[13:32.920 --> 13:35.860]  the image conversion is not triggered.
[13:37.520 --> 13:40.260]  And there is another thing here
[13:40.260 --> 13:44.160]  that if the image contains an invalid image header,
[13:44.160 --> 13:48.640]  the updating profile API aborts the process.
[13:48.640 --> 13:53.400]  So there is a good check in that image header.
[13:54.480 --> 13:56.680]  And it's using, of course, magic bytes,
[13:57.000 --> 13:59.600]  by checking the magic bytes.
[14:01.500 --> 14:07.620]  I like to test image conversion or processing softwares.
[14:07.620 --> 14:10.860]  Or whenever I see an API that is utilizing that
[14:11.380 --> 14:15.760]  or using that, I know for a fact that there is a large
[14:16.330 --> 14:19.500]  potential of having something bad happening.
[14:19.800 --> 14:24.220]  And the reason is because image conversion
[14:24.220 --> 14:29.440]  is not a vital functionality in an infrastructure
[14:29.440 --> 14:34.770]  of a company or even a web startup.
[14:36.520 --> 14:41.780]  So what happens is it often gets forgotten
[14:41.780 --> 14:43.880]  and there's no security updates
[14:43.880 --> 14:45.640]  that are being applied there.
[14:45.640 --> 14:47.880]  As far as it's working, then it's fine.
[14:47.880 --> 14:50.520]  This is something that I have seen as a pattern.
[14:51.140 --> 14:54.840]  And that's why I started testing that or focused on that.
[14:56.720 --> 15:00.320]  So one cool exploit here or security vulnerability
[15:00.780 --> 15:03.720]  that was released in 2016,
[15:03.720 --> 15:09.400]  it was known as the ImageTragic exploit or vulnerability.
[15:09.400 --> 15:13.620]  And this vulnerability allowed having remote code execution
[15:13.620 --> 15:18.880]  into the instance that is running the image processing
[15:18.880 --> 15:22.260]  when providing certain payloads.
[15:22.260 --> 15:25.940]  You can read more about the CVE offline.
[15:27.520 --> 15:29.660]  So I have tested this one
[15:29.660 --> 15:33.780]  and they seem to have this one patched.
[15:33.780 --> 15:38.080]  So I moved to the next one, it did not work.
[15:38.080 --> 15:40.900]  So I moved to the next one.
[15:44.900 --> 15:47.780]  There is a vulnerability in ImageMagick
[15:47.780 --> 15:50.240]  that was reported in 2017.
[15:50.700 --> 15:52.680]  And it works by having,
[15:52.680 --> 15:56.340]  whenever the palette is uninitialized
[15:57.380 --> 16:00.600]  or not presented in the GIF file, basically,
[16:02.860 --> 16:05.460]  ImageMagick leaks portions of the memory
[16:05.800 --> 16:08.400]  to the generated or the rendered image.
[16:09.800 --> 16:13.220]  And this is the fix for the vulnerability
[16:13.480 --> 16:18.280]  that was issued at that time around July, 2017.
[16:20.220 --> 16:23.740]  I generated a payload that renders this way
[16:24.320 --> 16:30.220]  in a normal browser or normal software that is patched.
[16:30.580 --> 16:35.400]  But when I upload the payload to Zoom,
[16:35.460 --> 16:37.780]  it renders this way.
[16:40.770 --> 16:44.490]  But if you are reading the report for that CVE,
[16:44.490 --> 16:47.150]  this is the typical behavior
[16:47.150 --> 16:51.550]  of having the exploit being successful.
[16:53.550 --> 16:57.430]  And if you download this image
[16:57.430 --> 17:06.290]  and try to obtain the strings from it,
[17:06.510 --> 17:10.930]  you will find that it's taking some portions of the memory.
[17:14.800 --> 17:19.660]  Then I thought that maybe this is an,
[17:19.660 --> 17:24.160]  let's say, image processing software fault
[17:24.600 --> 17:30.840]  or best effort just to render the image that is corrupted.
[17:30.840 --> 17:34.280]  Or there is a problem that is happening
[17:34.280 --> 17:37.360]  because of rendering a black image.
[17:37.360 --> 17:41.460]  So I generated a new one that is not the,
[17:41.460 --> 17:44.860]  like the payload, it's not the one that,
[17:44.860 --> 17:48.280]  this one has initialized palettes.
[17:49.360 --> 17:52.520]  And when I report it, it renders normally.
[17:53.300 --> 17:55.660]  Okay, this sounds really interesting.
[17:55.960 --> 17:59.220]  We have a memory leak on Zoom production.
[18:02.600 --> 18:06.820]  Typical thing is to automate the exploitation for that.
[18:06.820 --> 18:09.900]  And the flow for that would be
[18:09.900 --> 18:12.920]  to generate a new unique payload,
[18:12.920 --> 18:15.340]  then to upload it to Zoom,
[18:15.340 --> 18:18.260]  wait for the rendering to happen,
[18:18.260 --> 18:21.220]  download the rendered file,
[18:21.220 --> 18:23.620]  extract the data from the corrupted file
[18:23.620 --> 18:25.960]  that was rendered by Zoom,
[18:25.960 --> 18:30.160]  repeat and store leaked memory portions.
[18:32.340 --> 18:35.160]  So this proof of concept does that.
[18:36.000 --> 18:41.320]  So I'm going to have a demo time, which is cool.
[18:59.230 --> 19:03.990]  Here it generated the image and uploaded it to Zoom.
[19:08.480 --> 19:10.580]  I'm downloading the image now.
[19:11.700 --> 19:15.560]  And here, recovering the dump.
[19:43.780 --> 19:48.160]  So here, a memory leak on Zoom production
[19:48.620 --> 19:50.800]  was not the end for that.
[19:53.900 --> 19:58.320]  I remember that in 2018,
[19:58.320 --> 20:03.020]  Travis Romande released a research on Ghostscript,
[20:03.020 --> 20:06.860]  which was used by ImageMagick.
[20:07.020 --> 20:11.380]  And his research revealed a number of critical vulnerabilities
[20:11.380 --> 20:13.420]  in Ghostscript.
[20:13.680 --> 20:17.940]  And the proof of concept that he shared in the research
[20:17.940 --> 20:19.880]  when doing image conversion
[20:20.470 --> 20:25.620]  can lead to a remote code execution.
[20:25.700 --> 20:28.000]  And it was really cool to see this.
[20:28.000 --> 20:31.320]  And what I did is I used the proof of concept
[20:31.320 --> 20:34.280]  that Travis wrote.
[20:36.020 --> 20:40.460]  And I will show you this thing first.
[20:42.080 --> 20:48.500]  So we know for a fact that the 2016 v7.1.4,
[20:48.500 --> 20:50.960]  the image Tragic is patched.
[20:50.960 --> 20:54.200]  But we kind of think that the ImageMagick memory leak
[20:54.200 --> 21:00.660]  is presented based on the proof of exploitation we had here.
[21:02.720 --> 21:06.780]  And that one was patched and released,
[21:06.780 --> 21:09.900]  the patch was released in May 2016.
[21:09.900 --> 21:15.740]  And the patch for the memory leak was released in July 2017.
[21:15.940 --> 21:17.680]  And it's not patched.
[21:18.100 --> 21:22.220]  Based on that, we can safely say that
[21:24.580 --> 21:27.640]  the Ghostscript ROC is not patched, right?
[21:30.550 --> 21:36.330]  So I wrote, like I brought the proof of concept
[21:36.330 --> 21:40.550]  from the research that Travis Sormandy wrote.
[21:40.890 --> 21:46.250]  And I replicated it locally with the same environment
[21:46.250 --> 21:48.670]  I assume Zoom have it on their setup
[21:48.670 --> 21:57.830]  with the same range of versions that Zoom is using mostly.
[21:58.470 --> 22:00.780]  And yeah, it's working.
[22:04.490 --> 22:08.490]  Unfortunately for, or fortunately,
[22:08.490 --> 22:11.010]  I'm not sure which one would suit that,
[22:11.010 --> 22:16.970]  that Zoom API slash p slash upload checks for magic bytes.
[22:17.170 --> 22:20.790]  Otherwise a full exploitation would have been possible.
[22:21.730 --> 22:27.170]  But still, this does not mean that like Zoom is safe.
[22:27.170 --> 22:30.590]  If there is any particular API
[22:30.590 --> 22:32.890]  that is utilizing the same functionality
[22:34.250 --> 22:37.070]  and it's not checking the magic bytes,
[22:38.170 --> 22:41.770]  this would lead to a full remote code execution.
[22:42.110 --> 22:44.110]  This doesn't sound nice.
[22:44.110 --> 22:46.890]  This doesn't sound good by any means.
[22:50.920 --> 22:53.680]  And I don't know how to say this,
[22:53.680 --> 22:57.660]  but the RCE vulnerability is probably still there
[22:57.660 --> 22:59.440]  on Zoom production.
[23:04.400 --> 23:09.680]  Another thing we have here is the shadow IT and Zoom.
[23:14.240 --> 23:18.560]  I have noticed that there is a number of instances
[23:18.560 --> 23:23.340]  or cases where Zoom have shadow IT servers
[23:23.340 --> 23:26.060]  running in different host names
[23:27.300 --> 23:29.980]  and are not properly configured.
[23:29.980 --> 23:33.620]  And they may be a good target
[23:33.620 --> 23:37.220]  for conducting a successful attack.
[23:37.220 --> 23:40.000]  I have seen this in multiple occasions.
[23:40.000 --> 23:44.780]  This example here is showing an instance
[23:45.900 --> 23:50.440]  that did not have any patches since,
[23:50.820 --> 23:54.940]  let me check, September 10th, 2019.
[23:54.940 --> 23:58.740]  I took this picture in July 4th, 2020,
[23:58.740 --> 24:04.600]  around 10 or nine months of timeframe.
[24:04.600 --> 24:09.940]  There was no patches on that server or all new builds.
[24:11.200 --> 24:15.540]  And we all know that there was plenty of security vulnerabilities
[24:15.540 --> 24:18.260]  that was reported to them.
[24:18.260 --> 24:21.480]  And yeah, you can imagine.
[24:23.020 --> 24:26.680]  Another cool thing here is the same host
[24:26.680 --> 24:31.040]  had nine active connections, including me.
[24:31.700 --> 24:35.820]  Makes it an excellent fit for doing any type of testing
[24:35.820 --> 24:39.080]  without triggering alerts, which is cool,
[24:39.080 --> 24:43.400]  so that you can test it and be safe in the part
[24:43.400 --> 24:47.640]  that won't be as detected or detectable
[24:47.640 --> 24:53.660]  as in testing zoom.us, the main website, or yeah.
[24:55.930 --> 24:58.330]  Enough about all this,
[24:58.330 --> 25:02.470]  and let's start to talk about the Zoom app for Linux.
[25:06.990 --> 25:12.730]  One cool finding here, Zoom Linux client,
[25:12.730 --> 25:17.410]  so the TLS is broken by design on Linux,
[25:17.410 --> 25:20.130]  and you're gonna see how that is happening.
[25:20.510 --> 25:23.090]  I don't see this as the best practice,
[25:23.090 --> 25:28.330]  especially for the Zoom, but we can talk about that.
[25:28.330 --> 25:31.270]  So whenever there is any traffic that is intercepted
[25:31.270 --> 25:37.450]  with a custom TLS certificate, Zoom prompts this message.
[25:38.050 --> 25:41.070]  While it looks normal, everything is fine here.
[25:41.070 --> 25:43.850]  And whenever you click Trust Anyway,
[25:43.850 --> 25:50.530]  then you would have the traffic going with that,
[25:50.530 --> 25:52.790]  like with this accepted certificate,
[25:53.710 --> 25:55.790]  which is the unlisted one.
[25:59.840 --> 26:04.020]  But what happens here is that this certificate,
[26:04.020 --> 26:07.040]  like the fingerprint for this certificate
[26:07.440 --> 26:12.160]  is saved locally with the same permissions of the user.
[26:12.840 --> 26:17.920]  And you can simply just plug in,
[26:17.920 --> 26:22.920]  like if you have a malware that is able to have access
[26:23.660 --> 26:28.300]  to your machine, this malware can safely or easily
[26:28.780 --> 26:34.280]  just plug in to the fingerprint of the certificate,
[26:34.280 --> 26:36.880]  and then all of the traffic that is going to Zoom
[26:36.880 --> 26:42.800]  can be intercepted, even if it's using SSL or TLS,
[26:42.800 --> 26:47.560]  because the certificate will be accepted
[26:47.560 --> 26:50.760]  without having to have this type of prompts,
[26:50.760 --> 26:54.680]  because it was added to the local database
[26:56.040 --> 26:58.500]  on the background.
[26:59.160 --> 27:02.240]  So I wrote a simple proof of concept
[27:02.240 --> 27:06.900]  as a sample of what a malware would look like
[27:06.900 --> 27:11.980]  as just in a way or another as a concept.
[27:12.680 --> 27:16.580]  And this particular part of the malware
[27:17.000 --> 27:21.320]  or the proof concept would get the fingerprints
[27:21.320 --> 27:25.800]  for all of the forged certificates that we have.
[27:25.800 --> 27:30.800]  And then it would add it to the Zoom database,
[27:30.800 --> 27:34.940]  local database, and once it's added,
[27:34.940 --> 27:41.000]  these certificates can be provided to Zoom
[27:41.380 --> 27:45.960]  and all the traffic would be passing
[27:47.040 --> 27:50.660]  without having any error like this.
[27:50.660 --> 27:53.760]  And yeah, all of the encrypted traffic
[27:53.760 --> 27:58.460]  could be intercepted when having a malware
[27:58.460 --> 28:02.580]  running on the same user access as this one.
[28:04.860 --> 28:10.060]  Well, I have to say, this is not a really bad vulnerability.
[28:10.060 --> 28:14.760]  It's just a little bit not the best practice to do that.
[28:16.180 --> 28:18.260]  But as we are going now,
[28:18.260 --> 28:20.100]  we're gonna see something that is really bad
[28:20.620 --> 28:22.260]  and we're gonna see it now.
[28:23.740 --> 28:26.580]  So I would start with this question.
[28:27.580 --> 28:31.280]  What's a bad design for an application launcher?
[28:32.780 --> 28:33.880]  Good question.
[28:33.880 --> 28:35.700]  And we're gonna know the answer.
[28:35.700 --> 28:41.800]  So userbin slash zoom is a summary of OPT
[28:41.800 --> 28:45.360]  slash Zoom slash Zoom launcher.
[28:47.690 --> 28:50.790]  And whenever Zoom is called,
[28:52.390 --> 28:56.170]  Zoom is printing the following logging
[28:58.450 --> 29:01.590]  logging data on the SCD out.
[29:02.750 --> 29:05.630]  And there is a part where you can see
[29:06.650 --> 29:11.490]  Zoom path is OPT Zoom
[29:11.490 --> 29:15.070]  and then Zoom not exist at current directory.
[29:15.970 --> 29:18.570]  Okay, this looks interesting already.
[29:22.410 --> 29:24.790]  What's happening in the background?
[29:25.530 --> 29:29.010]  Zoom checks for files within PWD.
[29:29.760 --> 29:34.740]  And if there is an executable called Zoom, literally,
[29:35.770 --> 29:40.130]  on PWD, it executes it as a chat process
[29:40.860 --> 29:43.230]  for userbin Zoom.
[29:43.720 --> 29:45.860]  I was mind blown when I saw that.
[29:46.910 --> 29:50.090]  Why would this be there?
[29:50.190 --> 29:52.370]  This is a proof concept.
[29:53.040 --> 29:56.990]  I created a file called Zoom
[29:57.590 --> 30:01.750]  and then Zoom checks on the PWD
[30:01.750 --> 30:05.170]  if there is a file called Zoom, literally,
[30:05.870 --> 30:07.790]  and executes it.
[30:07.870 --> 30:10.870]  Of course, it has to be with an executable for permission,
[30:10.870 --> 30:13.070]  but this is not a thing.
[30:15.110 --> 30:21.550]  So imagine this, you have application-wide listing.
[30:21.590 --> 30:25.450]  There are a lot of points that I can make here,
[30:25.450 --> 30:26.470]  to be honest.
[30:26.470 --> 30:29.770]  I can make a lot of things that would show
[30:29.770 --> 30:33.770]  how this old design is there for.
[30:33.970 --> 30:38.210]  And if there's anything related to application-wide listing
[30:38.210 --> 30:40.430]  and your wide listing Zoom,
[30:41.290 --> 30:43.470]  this would literally break that
[30:44.150 --> 30:48.450]  because this is executed as a child process
[30:48.450 --> 30:51.570]  of a trusted application, Zoom.
[30:55.920 --> 30:58.700]  And yeah, it's bad practice and bad design
[30:58.700 --> 31:00.800]  by all means.
[31:00.800 --> 31:04.310]  Like why would this be implemented this way?
[31:07.870 --> 31:09.980]  So that's my answer.
[31:10.100 --> 31:12.860]  If it was a bad design for an application launcher,
[31:12.860 --> 31:16.880]  I would be Zoom application launcher for Linux.
[31:19.430 --> 31:21.920]  Another bad thing happening here.
[31:23.310 --> 31:27.990]  So the Zoom local database implementation,
[31:30.610 --> 31:32.220]  you'll see now.
[31:33.570 --> 31:35.870]  So in the configuration files
[31:35.870 --> 31:38.890]  of the configuration directory of Zoom,
[31:40.210 --> 31:42.450]  there is this file,
[31:42.450 --> 31:46.310]  the local database is zoomus.db.
[31:46.310 --> 31:48.450]  This is the default database
[31:48.450 --> 31:52.410]  and a lot of other files that are there for Zoom.
[31:53.310 --> 31:56.270]  The most important file is the zoomus
[31:56.270 --> 31:58.390]  because it has the access tokens,
[31:58.390 --> 32:02.630]  it has all of the PII for the user and everything.
[32:03.620 --> 32:07.260]  And as we can see here in the screen,
[32:07.870 --> 32:13.930]  the file permission is 644.
[32:14.680 --> 32:16.180]  I'll show you this.
[32:19.160 --> 32:20.580]  644.
[32:20.580 --> 32:26.960]  This gives to the user a write and read access.
[32:27.420 --> 32:29.700]  Okay, sounds reasonable.
[32:29.700 --> 32:32.270]  Nothing bad on that.
[32:33.270 --> 32:39.150]  Group access to give it read access.
[32:39.150 --> 32:40.750]  Why?
[32:40.870 --> 32:43.130]  I really like, really?
[32:43.130 --> 32:45.590]  Are you sure about that?
[32:46.830 --> 32:51.930]  But everyone to have read access
[32:51.930 --> 32:56.570]  into the Zoom local database
[32:56.570 --> 32:59.370]  of the Zoom user.
[32:59.890 --> 33:00.910]  Why?
[33:00.910 --> 33:03.410]  Literally, that's what I had in mind.
[33:06.280 --> 33:10.240]  Any code on the user machine that have access to the,
[33:10.240 --> 33:12.740]  like any code that have access to the user machine
[33:12.740 --> 33:17.220]  can read and exfiltrate Zoom local database
[33:17.220 --> 33:22.220]  and configurations and more, of course.
[33:22.860 --> 33:27.420]  Because the permission or the file permission
[33:27.420 --> 33:34.540]  for the Zoom local database is set to be read by everyone.
[33:37.800 --> 33:42.460]  And, okay, another thing that is quite cool.
[33:43.300 --> 33:46.460]  Zoom is end-to-end encrypted.
[33:46.860 --> 33:48.020]  Is it?
[33:48.940 --> 33:54.220]  We can see later, but my answer is not fully.
[33:55.860 --> 34:01.600]  One awesome product by Zoom is Zoom chat.
[34:01.600 --> 34:05.860]  And it's advertised in the website
[34:05.860 --> 34:10.230]  and that we can see here
[34:12.000 --> 34:15.780]  as a platform that is,
[34:15.780 --> 34:20.280]  that makes work and collaboration much easier
[34:20.280 --> 34:22.180]  in mobile and desktop
[34:22.180 --> 34:27.260]  and with a really clean design and UI
[34:27.920 --> 34:32.760]  that looks kind of similar to what Slack is having.
[34:32.860 --> 34:34.500]  This is not the point,
[34:34.500 --> 34:38.180]  but it looks good as a product, right?
[34:39.560 --> 34:44.380]  And as we go back here is, yeah.
[34:45.900 --> 34:47.980]  There are so many cool things to read,
[34:47.980 --> 34:50.140]  but I would focus on the security part.
[34:51.140 --> 34:55.160]  As we can see in the security and archiving and in I-Code,
[34:55.160 --> 35:01.660]  Zoom encrypts data at all times.
[35:01.980 --> 35:06.800]  Again here,
[35:06.800 --> 35:11.640]  encryption of data in transit and at rest
[35:11.640 --> 35:17.800]  and then encryption for data and mobile devices.
[35:18.640 --> 35:22.060]  Your messages in this chat are secured.
[35:22.080 --> 35:23.640]  Another one.
[35:23.940 --> 35:27.060]  So there are a lot of advertisement
[35:27.060 --> 35:32.180]  that is going with how secure Zoom chat is happening.
[35:32.300 --> 35:35.200]  And by security, they don't really
[35:35.200 --> 35:38.660]  or necessarily talk about application security,
[35:38.660 --> 35:41.480]  level of security,
[35:42.420 --> 35:45.700]  but they are talking about how all of the data
[35:45.700 --> 35:49.240]  that are being passing here is encrypted
[35:49.240 --> 35:52.020]  both at rest and in transit,
[35:52.840 --> 35:56.980]  which is in transit, I assume they're saying
[35:56.980 --> 35:59.520]  that it goes in SSL.
[35:59.520 --> 36:00.800]  It's cool.
[36:01.300 --> 36:04.280]  But at rest, this means that they have full
[36:04.280 --> 36:06.780]  end-to-end encryption happening, right?
[36:09.760 --> 36:13.520]  And yeah, repeating again the same sentences.
[36:15.740 --> 36:17.640]  And let's pause this.
[36:46.960 --> 36:49.580]  I'm not sure.
[36:51.060 --> 36:53.360]  This way is fine.
[36:53.580 --> 36:56.740]  But on the right screen, we have Zoom chat running
[36:56.740 --> 37:04.420]  and I have my group chat that is clear with no messages.
[37:04.420 --> 37:07.800]  And then I'm sending some sort of an encrypted message
[37:08.600 --> 37:14.080]  that is here because Zoom is E2E by now,
[37:14.860 --> 37:16.800]  E2E encrypted by now.
[37:17.700 --> 37:19.680]  As advertised.
[37:19.680 --> 37:24.340]  And then on the left side, we can see the local database,
[37:25.800 --> 37:28.400]  a custom one that is made by Zoom
[37:29.580 --> 37:33.320]  that we can see that they have it.
[37:33.320 --> 37:37.180]  And I can just read what's happening there
[37:37.530 --> 37:41.540]  and what they are storing on your local device.
[37:44.950 --> 37:47.230]  So here I sent a message
[37:47.230 --> 37:51.810]  and it's saying that this is secret.
[37:52.630 --> 37:55.770]  Oh, well, just one second.
[37:55.770 --> 37:57.190]  I have to repeat that.
[38:12.650 --> 38:20.370]  The message is being stored locally at rest in clear text.
[38:24.630 --> 38:29.130]  And here, anyone who is able to have access
[38:29.130 --> 38:32.570]  to the user machine is able to pull a full archive
[38:32.570 --> 38:35.410]  of all messages that are being sent
[38:35.990 --> 38:40.830]  that were or are supposed to be end-to-end encrypted
[38:40.830 --> 38:43.950]  and it's saved in plain text.
[38:45.450 --> 38:47.450]  And yeah, this does not sound good.
[38:47.450 --> 38:51.010]  And it's not the one that you can have a record
[38:51.010 --> 38:52.630]  or a backup for your messages.
[38:52.630 --> 38:58.050]  It's just a debugging feature that they left open
[38:58.780 --> 39:03.230]  in production for the Linux build.
[39:03.270 --> 39:08.490]  I'm not sure if this is applicable in macOS or in Windows,
[39:08.490 --> 39:15.990]  but you can see if that's being applicable here in Linux.
[39:18.450 --> 39:22.270]  By the way, the fact that the same database
[39:22.270 --> 39:26.280]  that for messages is having the 644,
[39:26.750 --> 39:27.910]  where is it?
[39:27.910 --> 39:31.110]  The 644 user permission,
[39:31.110 --> 39:34.390]  which means that any code that is running
[39:34.390 --> 39:38.810]  despite what type of user permission is running
[39:38.810 --> 39:45.690]  is able to access this end-to-end encrypted chat archive.
[39:45.910 --> 39:47.390]  Doesn't sound good.
[39:49.490 --> 39:54.410]  Yeah, so of course I could have gone more and tested more,
[39:54.410 --> 39:57.950]  but at the end, this is just a time
[39:57.950 --> 40:03.370]  that I have spending just to fuzz around with Zoom.
[40:03.370 --> 40:08.670]  I did this for curiosity purposes mainly,
[40:09.530 --> 40:12.930]  but definitely I could have spent more time.
[40:13.950 --> 40:18.850]  But then, yeah, I jumped to the responsible disclosure now,
[40:18.850 --> 40:24.390]  and I started the experiment in around April.
[40:24.410 --> 40:29.010]  April 15, reported that in April 18,
[40:29.010 --> 40:32.910]  I contacted Lotus Security in Twitter,
[40:33.570 --> 40:41.670]  followed up with the vulnerability disclosure again on 26,
[40:41.670 --> 40:46.850]  couple of messages on the background.
[40:46.850 --> 40:50.570]  And May 5th of 2020,
[40:50.570 --> 40:54.560]  I received request closed to memory leak at Zoom.us.
[40:55.670 --> 40:57.560]  Yeah, here.
[40:58.570 --> 41:00.680]  So yeah, I wasn't happy.
[41:05.420 --> 41:07.950]  So what's next?
[41:07.950 --> 41:10.200]  Tweeted about that.
[41:11.090 --> 41:16.370]  And then I was asked to send it via HackerOne,
[41:16.370 --> 41:20.930]  turn on communication running to run my automated exploit
[41:20.930 --> 41:23.950]  for the memory leak.
[41:24.430 --> 41:29.630]  Then when nothing seems to be happening,
[41:29.630 --> 41:32.010]  I informed Zoom that I'm planning to present
[41:32.010 --> 41:35.350]  my ongoing research here at DEF CON.
[41:36.250 --> 41:42.050]  And then Zoom told me that they cannot assess the issue
[41:42.050 --> 41:45.450]  as there was no sensitive data seen
[41:46.490 --> 41:49.130]  despite the predictability of the vulnerability
[41:49.130 --> 41:50.690]  on the provided exploit.
[41:51.730 --> 41:56.550]  Then it was closed as not applicable.
[41:58.410 --> 41:59.990]  Sure.
[42:02.520 --> 42:06.180]  Then I sent on July 11th,
[42:06.180 --> 42:08.680]  my new research results,
[42:08.680 --> 42:12.480]  reporting new seven different security vulnerabilities,
[42:13.360 --> 42:16.200]  six to seven new vulnerabilities.
[42:16.940 --> 42:20.660]  I got an acknowledgement about receiving my report.
[42:20.660 --> 42:24.700]  By the way, this is the first conclusive response
[42:24.700 --> 42:27.400]  regarding the memory leak issue.
[42:29.100 --> 42:33.640]  By conclusive, I mean that they did a full analysis
[42:33.640 --> 42:35.100]  of what was happening.
[42:35.100 --> 42:37.700]  On the previous ones on HackerOne,
[42:37.700 --> 42:40.520]  they triggered it as valid,
[42:40.520 --> 42:43.260]  and then they were trying to run my exploit,
[42:43.260 --> 42:44.900]  and that's all.
[42:45.060 --> 42:49.740]  But this one, they researched more and analyzed more
[42:49.740 --> 42:51.040]  about how this is happening
[42:51.040 --> 42:53.340]  and what was the cause of the issue.
[42:53.800 --> 42:57.720]  And it was in like literally three months
[42:57.720 --> 42:59.570]  after I reported it.
[43:00.800 --> 43:03.200]  Then further explanation from Zoom
[43:03.200 --> 43:06.860]  regarding the vulnerability or the findings in general.
[43:08.520 --> 43:12.500]  Okay, now with what was happening
[43:12.500 --> 43:15.960]  and then from their explanation,
[43:15.960 --> 43:19.540]  and then my response regarding each analysis
[43:19.540 --> 43:21.080]  that they provided.
[43:24.180 --> 43:26.700]  So for the public authentication,
[43:26.700 --> 43:28.600]  yeah, you can see what's happening here,
[43:28.600 --> 43:30.600]  what they wrote.
[43:31.200 --> 43:33.380]  And well, yeah, for me, yeah.
[43:33.380 --> 43:36.260]  Well, again, this may be a forgotten server
[43:36.260 --> 43:38.740]  that was mistakenly exposed.
[43:38.740 --> 43:42.780]  I haven't seen any references of 2FA being implemented,
[43:43.820 --> 43:46.500]  but in all cases, it's down now, so it's great.
[43:48.740 --> 43:54.300]  Oh, wait, I think I messed up with the messages here.
[43:54.380 --> 44:00.980]  Anyway, so this is the same slide from the last one.
[44:04.120 --> 44:07.480]  So we did check that ImageMagick
[44:08.680 --> 44:11.980]  is not used for image conversions here,
[44:13.080 --> 44:17.360]  but wait, the same vulnerability is being reproduced.
[44:17.360 --> 44:19.200]  It's maybe a fork of ImageMagick
[44:19.710 --> 44:21.680]  or an image processing software
[44:21.680 --> 44:24.020]  that is vulnerable to the same CVE
[44:25.160 --> 44:29.360]  of not being able to parse GIF images
[44:29.770 --> 44:33.560]  that have an initialized palettes.
[44:34.060 --> 44:37.180]  This sounds reasonable.
[44:37.180 --> 44:41.340]  In all cases, it's clear that something is wrong, right?
[44:44.660 --> 44:48.120]  Shadow IT and Zoom.
[44:48.120 --> 44:53.200]  So these are non-sensitive information disclosure
[44:53.200 --> 44:55.200]  from a shared environment.
[44:55.560 --> 44:57.940]  Information hygiene is important to us
[44:57.940 --> 45:00.820]  and we appreciate you reporting this finding.
[45:00.820 --> 45:01.900]  So that's great.
[45:01.900 --> 45:03.640]  So Full Hunt can help here,
[45:03.640 --> 45:05.160]  probably the best product out there
[45:05.160 --> 45:07.840]  for mitigating shadow IT risks.
[45:10.880 --> 45:14.900]  Oh, I think part of the discussion
[45:14.900 --> 45:17.880]  regarding the image conversion
[45:17.880 --> 45:21.080]  is not placed on the slide,
[45:21.080 --> 45:23.180]  but please check my blog after that
[45:23.180 --> 45:27.180]  to have the full list of discussion.
[45:27.640 --> 45:33.020]  So for what was happening for the Linux app findings,
[45:33.020 --> 45:38.410]  yeah, they fixed it or patched it in 5.2.0
[45:38.760 --> 45:42.840]  that was released in August 3rd, I think.
[45:43.480 --> 45:47.360]  They were supposed to patch or release it on August 2nd,
[45:47.360 --> 45:50.120]  but it was released on August 3rd.
[45:50.120 --> 45:53.920]  In all cases, I have read the change log.
[45:53.920 --> 46:00.140]  There was no mention whatsoever for any security patches.
[46:00.140 --> 46:03.600]  So clearly it was a silent fix,
[46:03.600 --> 46:06.700]  which it wasn't a nice thing.
[46:06.700 --> 46:11.020]  At least users should have some transparency
[46:11.020 --> 46:13.980]  of the state of security for the company
[46:13.980 --> 46:16.280]  that they use or trust.
[46:24.490 --> 46:25.990]  Yeah, the patches.
[46:25.990 --> 46:30.150]  I just told you about the patches
[46:30.150 --> 46:34.240]  for what happened for the Zoom Linux app.
[46:35.390 --> 46:40.680]  For what was happening with the image conversion,
[46:41.170 --> 46:43.470]  they decided to not patch it
[46:43.470 --> 46:46.250]  because they are not seeing sensitive data
[46:46.250 --> 46:51.310]  and then that are being exposed.
[46:52.150 --> 46:55.660]  Then what happened is they asked,
[46:56.550 --> 47:00.430]  they stated that they are not using image magic,
[47:00.430 --> 47:05.030]  but still the same behavior of the vulnerability
[47:05.030 --> 47:08.310]  is being reproduced as a result of the image conversion.
[47:08.310 --> 47:11.330]  So clearly something bad is happening,
[47:11.330 --> 47:14.630]  but I'm not a part of Zoom
[47:15.120 --> 47:19.310]  or I don't have a say on Zoom to have them fix that.
[47:19.310 --> 47:24.310]  So my responsibility is just to,
[47:24.310 --> 47:27.190]  as part of the research that I'm conducting,
[47:27.190 --> 47:29.630]  is to just let them know.
[47:29.630 --> 47:30.710]  And that's all.
[47:31.690 --> 47:33.050]  What else?
[47:33.350 --> 47:35.510]  The findings, the shadow IT,
[47:35.510 --> 47:40.510]  I'm not sure if they started reviewing
[47:41.270 --> 47:43.450]  all of their shadow IT instances.
[47:43.450 --> 47:46.150]  That's something that they are supposed to do.
[47:46.150 --> 47:48.830]  For the Kerberos server, they took it down,
[47:48.830 --> 47:50.910]  which is good, which is awesome.
[47:52.630 --> 47:56.430]  And yeah, they told us,
[47:56.430 --> 47:58.570]  they told me that they are patching
[47:58.570 --> 48:01.330]  all of the vulnerabilities for the Linux app
[48:01.330 --> 48:07.990]  on the release of August 2nd or August 3rd.
[48:07.990 --> 48:11.270]  It was released with no mention
[48:11.270 --> 48:15.570]  for any security fixes or updates.
[48:18.260 --> 48:22.780]  Yeah, for me, it was a difficult experience
[48:22.780 --> 48:27.400]  to be able to report these vulnerabilities to them.
[48:27.400 --> 48:30.260]  In the beginning, there was a lack of communication,
[48:30.260 --> 48:31.820]  despite all of what was happening
[48:31.820 --> 48:34.780]  or that I was hearing in the media.
[48:35.900 --> 48:39.040]  Every now and then, I see that Zoom has patched
[48:39.620 --> 48:41.280]  a critical or severe vulnerability
[48:41.280 --> 48:47.020]  that was even attacking things that are less riskier
[48:47.020 --> 48:48.680]  than what I have found,
[48:48.680 --> 48:53.840]  but it was generating a lot of media PR
[48:53.840 --> 48:57.420]  that is bad for or negative to Zoom.
[48:57.420 --> 49:00.460]  And I assume that was the reason
[49:00.460 --> 49:03.140]  why they are patching it that quickly,
[49:03.800 --> 49:08.420]  comparing to my experience to Zoom VDP.
[49:10.080 --> 49:13.340]  And yeah, of course, I did not release anything
[49:13.340 --> 49:16.140]  that I found before this talk.
[49:17.880 --> 49:23.400]  To other parties or unauthorized parties.
[49:25.540 --> 49:29.140]  And yeah, so it was not mentioned in the media before.
[49:29.140 --> 49:31.340]  I did not share it with anyone in the media.
[49:31.340 --> 49:35.360]  That's probably one reason it wasn't that fixed
[49:35.360 --> 49:37.420]  or my experience wasn't as the same
[49:37.420 --> 49:40.780]  as the vulnerabilities that was shared in the media.
[49:41.280 --> 49:43.040]  And that's one thing.
[49:43.140 --> 49:45.920]  I'm not sure, but I would be surprised
[49:45.920 --> 49:50.040]  if I'm the only researcher in the world
[49:50.040 --> 49:54.220]  that had this experience with Zoom security.
[49:54.220 --> 49:56.740]  I would be really surprised about that.
[49:58.060 --> 50:03.400]  Another part is the massive growth versus security.
[50:04.820 --> 50:08.160]  Zoom has massively grown in 2020
[50:08.480 --> 50:11.300]  in a way that no one could have imagined.
[50:11.820 --> 50:14.500]  Zoom has been here forever.
[50:14.500 --> 50:18.780]  And what the growth that they got during 2020
[50:20.160 --> 50:23.440]  was something that for me,
[50:23.440 --> 50:26.520]  it was like no one would have expected this to happen.
[50:28.580 --> 50:32.100]  And this reflected a lot on the security.
[50:32.100 --> 50:36.620]  A lot of people have a clear focus on the security of Zoom
[50:36.620 --> 50:40.100]  since it became a part of our lives.
[50:40.820 --> 50:42.200]  Everyone is using it.
[50:42.200 --> 50:45.760]  I use it, my company use it,
[50:45.760 --> 50:49.000]  everyone that I know use Zoom.
[50:50.400 --> 50:55.000]  And that's why security is extremely important now for Zoom.
[50:55.100 --> 51:00.040]  And the thing is having security means
[51:00.040 --> 51:03.260]  that you have to have a full security program running.
[51:03.300 --> 51:06.540]  It's not that easy to have a full security program.
[51:06.540 --> 51:10.060]  And there are a lot of things to consider when doing that.
[51:10.560 --> 51:14.260]  For me, when I build security programs in companies,
[51:14.260 --> 51:18.220]  I take a lot of time to do that.
[51:18.220 --> 51:20.240]  And this is a typical thing.
[51:20.360 --> 51:23.280]  Even if we have the highest budget,
[51:24.600 --> 51:26.780]  similar to what Zoom is having,
[51:26.780 --> 51:33.520]  it does not come to how much budget is allocated to Zoom,
[51:34.120 --> 51:35.340]  to Zoom security.
[51:35.340 --> 51:37.680]  It's about different processes
[51:37.680 --> 51:41.620]  that should have been already done before the pandemic.
[51:42.840 --> 51:45.540]  And having a last-minute security program
[51:45.540 --> 51:48.100]  or a last-minute VDP,
[51:48.600 --> 51:50.520]  Probability Disclosure Program,
[51:51.500 --> 51:55.820]  is not easy and can cause a lot of errors
[51:55.820 --> 51:58.180]  and mistakes happening.
[51:59.060 --> 52:02.740]  Lack of communications and focus.
[52:02.740 --> 52:06.820]  These type of patterns that I have seen with Zoom
[52:06.820 --> 52:09.440]  is something that are possibly happening
[52:09.440 --> 52:11.020]  to all of the researchers
[52:11.720 --> 52:17.120]  that have been reporting to Zoom responsibly.
[52:18.500 --> 52:21.480]  I'm just saying that there is a lot of work
[52:21.480 --> 52:25.100]  for the security program at Zoom to be done.
[52:27.110 --> 52:28.490]  The reward?
[52:28.490 --> 52:30.070]  Yeah, that's another thing.
[52:32.050 --> 52:35.150]  One thing that I also seen that Zoom accounts
[52:35.780 --> 52:39.550]  like have as advertised a bug bounty program
[52:40.440 --> 52:44.370]  and then have the reward for all of the research
[52:44.370 --> 52:48.670]  that they have conducted as zero USD.
[52:48.930 --> 52:50.550]  This is not a...
